home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 500 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  7.2 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: PPC compilers
  5. Date: 8 Jan 1996 16:04:57 GMT
  6. Organization: Teleport - Portland's Public Access (503) 220-1016
  7. Message-ID: <4crfb9$djs@maureen.teleport.com>
  8. References: <john.hendrikx.40ka@grafix.xs4all.nl> <4b77tq$htp@serpens.rhein.de> <MQAQx*XOe@yaps.rhein.de> <4bqhnf$6g5@sunsystem5.informatik.tu-muenchen.de> <jasonb.820051107@cs.uwa.edu.au> <4c9i2l$h3i@sunsystem5.informatik.tu-muenchen.de> <4cf0ep$233@ra.i
  9.   <4ck47h$g07@maureen.teleport.com> <jasonb.820919731@cs.uwa.edu.au> <4com6v$415@maureen.teleport.com> <jasonb.821098303@cs.uwa.edu.au>
  10. NNTP-Posting-Host: julie.teleport.com
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Jason S Birch (jasonb@cs.uwa.edu.au) wrote:
  14. : sschaem@teleport.com (Stephan Schaem) writes:
  15.  
  16. : >Jason S Birch (jasonb@cs.uwa.edu.au) wrote:
  17. : >: sschaem@teleport.com (Stephan Schaem) writes:
  18. : >: >Lars Duening (duening@ibr.cs.tu-bs.de) wrote:
  19. : >: >: If a have to access hardware registers (never had to so far), I will
  20. : >: >: not do this by direct pointers, but instead define a structure
  21. : >: >: representing them. This is then the only place where I have to worry
  22. :                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  23. : >: >: about .c, .w and .l, everywhere else I can write 
  24. :       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  25. : >: >: 'chipregs->blt0con = *b++;' and let the compiler figure the rest out.
  26. :       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  27. : >: >: HLLs win again here: the compiler will warn if *b is of the wrong
  28. :                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  29. : >: >: type, and if I defined the structure wrong (your .w/.l example), I
  30. :       ^^^^
  31. : >: >: just have to correct the structure, not the n statements where it is
  32. : >: >: used. And the compiler would even take care of bitshifts where
  33. : >: >: necessary.
  34.  
  35. : >: > You let the compiler tell you AFTER you write your code about the type?
  36.  
  37. : >: That's not what he said. He said the only place he has to worry about .c, .w
  38. : >: and .l is where he's defining his structures (although even then, it would be
  39. : >: extremely rare) and after that he can just use his new types, relying on the
  40. : >: compiler to give a warning if he's made a mistake.
  41.  
  42. : > I dont think he can declare like this:   chipregs.bltcon0  con0;
  43. : > So he will need so 'worry' about it when he declare con0, he will
  44. : > read ushort when peeking the structure (Like the asm coder) or
  45. : > maybe he typedefed  ushort  chipreg; and will use this instead.
  46. : > *b could be a pointer to float for all he cares, dont you think its
  47. : > wise to know what data your are manipulating so you can declare your
  48. : > variable correctly?!?!
  49.  
  50. : Again: *If* he's trying to create a data type with certain
  51. : implementation-dependent size-requirements (such as in the bltcon0
  52. : case, assuming no headers to give us one) *then*, at that point in
  53. : time, he has to know the size of the type in order to define it
  54. : correctly. He stated that earlier - check what I've underlined.
  55.  
  56.  He said he would create a structure... not a new type.
  57.  Now, tell me how he can forget that chipregs->bltcon0 is
  58.  of type UWORD when he will declar *b and use *b (I guess you
  59.  could forget what type are your variable, but personaly think its
  60.  not to wise) 
  61.  
  62.  I'm sorry again , I dont see how you can program not knowing  
  63.  the type of your variable when you use them? Is it a pointer to a
  64.  string C string? a pointer to a P String? Should I mask the variable
  65.  before I shift? etc...
  66.  
  67. : However, once done, he can then safely create variables of that type
  68. : (the abstract one he's defined, which happens to be the right size) and
  69. : safely assign appropriate values to them, without having to worry if
  70. : the eventual assignments are implemented as a .c, .w, or .l. He can
  71.  
  72.  He defined a structure not a type... read what you underlined.
  73.  
  74.  move.type    (a0),(a1) ... so what if type read .word or .chipreg
  75.  
  76.  In asm you are forced to write what your thinking in all its detail,
  77.  this mean forced to know your variable type. Something you should do
  78.  even in C.
  79.  
  80. : safely rely on the compiler to produce the correct code, and warn him
  81. : if he's trying to assign an inappropriate value. *b must be a pointer
  82. : to the correct type that he's defined, and as he said, the compiler
  83. : will warn him if *b is the wrong type. That's all.
  84.  
  85.  I agree its a feature of the compiler, something you can rule out on
  86.  assembler. I just desagree that its something to rely on to declare and
  87.  forget.
  88.  
  89. : >: He needs to know how he's defined it, yes - but not whether it turns into a .c,
  90. : >: .w, or .l. It could be written as a UCHAR, a LONG, or even typedef'd to a
  91. : >: BILBY. Read it again.
  92.  
  93. : > He needs to know how he declared it too... meaning he has to know when
  94. : > he write the code what is the type on bltcon0.. a uword or a BILBY (typdef
  95. : > for uword)... And if he as a few brain cell left he will remember that
  96. : > when he use the variable. EX when I declare float, long in a function
  97. : > I know wich is wich otherwise I might store a float temp result
  98. : > in a long and bang!
  99.  
  100. : The question is not about whether you need to know if a variable is a
  101. : float or a long, since they are "abstract" types (and can be different
  102. : sizes on different machines). The question is whether you need to know
  103. : how many bits are in each, and what each bit means. In assembler, you
  104. : do need to know the former, and occasionally the latter.
  105.  
  106.  When you program in C... on what basis do you select your variable type?
  107.  Do you limit yourself to int/float? for all integer work you use int, 
  108.  and real you use float?
  109.  
  110.  In C or asm I choose type according the the min range they hold.
  111.  I cant imagine choosing a type for my operation without knowing the
  112.  type range.
  113.  
  114. : >: > Yea, I agree... move.w (ax)+,(a1)+ just mean : "Copy 2 bytes from a0 to
  115. : >: > a1, and increment both address by 2"
  116. : >: > In C the equivalent to move.? (a0)+,(a1)+ is
  117. : >: > A++ = B++;
  118. : >: > And that beying defined somewhere:
  119. : >: > ushort    *A,*B;
  120.  
  121. : >: That's only the C equivalent on certain platforms. C itself says nothing about
  122. : >: the actual size of its various types, other than a relative ordering.
  123.  
  124. : > ANSI define very well the minimum size of its type.
  125.  
  126. : It does *not* define that ushort is the same as two bytes, which is
  127. : what you are claiming above as being equivalent. It only guarantees
  128. : that char <= short <= long.
  129.  
  130.  It define that ushort can hold value from 0 to 65535... this is what I
  131.  claim. ANSI C do define min range for the basic types, it would be
  132.  unthinkable otherwise.
  133.  
  134. : > Yes, thats very true... in asm you only have fixed type. But typedef is
  135. : > not really a part of the compiler but preprocessor, and could be easely
  136. : > integrated to an assembler.(But its not, so its hell when you modify
  137. : > structure)
  138.  
  139. : >#typedef .w .chipreg
  140.  
  141. : > move.chipreg    (GLOBAL_x1,a4),(CHIPREG_bltcon0,a1)
  142.  
  143. : typedef really is part of the compiler, not the preprocessor.
  144. : Unfortunately, given the notice C takes of typedefs you've made, it
  145. : may as well be part of the preprocessor. :-( 
  146. : (ie. typedef xxx foo;
  147. :      typedef xxx bar;
  148.  
  149. :      foo x;
  150. :      bar y;
  151.  
  152. : I would hope x = y to at least give a warning, even if they are
  153. : actually the same type.)
  154.  
  155.  I agree the above should at least give a warning.
  156.  
  157.  Stephan
  158.